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ABSTRACT 



A system and method for configuring routing resources of a 
programmable logic device arc presented in various embodi- 
ments. In one embodiment, a first function is provided that 
automatically generates configuration bits for configuration 
of routing resources to connect a source to a sink. The input 
parameters to the to the first function include the source and 
the sink. A second function is provided to automatically 
generate configuration bits for configuration of routing 
resources that connect a source to a plurality of sinks. The 
second function is responsive to input parameters specifying 
the source and plurality of sinks. Additional program inter- 
faces are provided and each provides various controls over 
the routing process. 

23 Claims, 10 Drawing Sheets 
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RUN-TIME ROUTING FOR 
PROGRAMMABLE LOGIC DEVICES 

RELATED PATENT APPLICATIONS 

This patent application is related to the following 
co-pending patent applications: 

1. U.S. patent application Ser. No. 08/919,531, entitled, 
"METHOD OF DESIGNING FPGAS FOR DYNAMI- 
CALLY RECONFIGURABLE COMPUTING," filed on :0 
Aug. 28, 1997 by Steven A. Guccione; and 

2. U.S. patent application Ser. No. 09/168,300, entitled 
"CONFIGURATION OF PROGRAMMABLE LOGIC 
DEVICES WITH ROUTING CORES", filed Oct. 7, 1998 
by Steven Guccione and Delon Levi. 15 

The contents of the above applications are incorporated 
herein by reference. 

GOVERNMENT CONTRACT 

20 

The U.S. Government has a paid-up license in the above 
referenced invention and the right in limited circumstances 
to require the patent owner to license others on reasonable 
terms as provided for by the terms of DABT63-99-3-0004 
awarded by DARPA. u 

FIELD OF THE INVENTION 

The present invention generally relates to configuration of 
programmable logic devices, and more particularly to run- 
time configuration of routing resources. 30 

BACKGROUND 

Field programmable gate arrays (FPGAs), first introduced 
by XILINX in 1985, are becoming increasingly popular 35 
devices for use in electronics systems. For example, com- 
munications systems employ FPGAs in large measure for 
their re-programmability. In general, the use of FPGAs 
continues to grow at a rapid rate because they permit 
relatively short design cycles, reduce costs through logic 4Q 
consolidation, and offer flexibility in their 
re-programmability. 

The field of rcconfigurablc computing has advanced 
steadily for the past decade, using FPGAs as the basis for 
high-performance reconfigurablc systems. Run-Time 45 
Reconfigurable (RTR) systems distinguish themselves by 
performing circuit logic and routing customization at run- 
time. RTR systems using FPGAs are expected to result in 
systems that require less hardware, less software, and fewer 
input/output resources than traditional FPGA-based sys- 50 
terns. However, scarcity of software that supports RTR is 
believed to be one reason that RTR has been outpaced by 
research in other areas of reconfigurable computing. 

Whereas with traditional configuration of FPGAs the time 
taken to generate a programming bitstream is generally not 55 
real-time critical, with RTR systems, the time required to 
generate the programming bitstream may be critical from the 
viewpoint of a user who is waiting for the FPGA to be 
reconfigured. Thus, it may be acceptable to take hours to 
generate a programming bitstream using traditional configu- <>q 
ration methods. In a runtime environment, however, it is 
expected that the reconfiguration process require no more 
than a few seconds or even a fraction of a second. 

Reconfiguration of a FPGA may include routing and 
rerouting connections between the logic sections. Routers in 65 
a traditional configuration process generally route connec- 
tions for all the circuit elements. That is, these routers define 
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connections for all the circuit elements in a design, expend- 
ing a great deal of time in the process. In an RTR 
environment, traditional routing methods are inappropriate 
given the real-time operating constraints. Present run-time 
routing methods provide a great deal of program control 
over the routing process. For example, the JBits program 
from Xilinx allows a program to manipulate individual bits 
in the configuration bitstream for configuring routing 
resources. While this approach provides a great deal of 
flexibility, the drawback is added program complexity. 

A system and method that addresses the aforementioned 
problems, as well as other related problems, is therefore 
desirable. 

SUMMARY OF THE INVENTION 

A system and method for configuring routing resources of 
a programmable logic device are presented in various 
embodiments. In one embodiment, a first application pro- 
gramming interface is provided which automatically gener- 
ates configuration bits for configuration of routing resources 
to connect a source to a sink. The input parameters to the to 
the first interface include the source and the sink. A second 
programming interface is provided to automatically generate 
configuration bits for configuration of routing resources that 
connect a source to a plurality of sinks. The second interface 
is responsive to input parameters specifying the source and 
plurality of sinks. Additional program interfaces arc pro- 
vided to allow greater control over the routing process. 

It will be appreciated that various other embodiments are 
set forth in the Detailed Description and Claims which 
follow. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Various aspects and advantages of the invention will 
become apparent upon review of the following detailed 
description and upon reference to the drawings in which: 

FIG. 1 is a flow chart illustrating the design of a circuit 
implemented in an FPGA using a reconfigurable logic 
coprocessor; 

FIG. 2 is a block diagram of a system 200 for configu- 
ration of a programmable logic device 202, according to one 
embodiment of the invention; 

FIG. 3 is a flowchart of a process for initial configuration 
and run-time reconfiguration of a programmable logic 
device; 

FIG. 4 is a functional block diagram that illustrates 
various configurable routing resources of a programmable 
logic device; 

FIG. 5 is a block diagram illustrating a partial row of 
configurable logic blocks (CLBs) and general routing matri- 
ces (GRMS) for an FPGA; 

FIG. 6 is a block diagram illustrating routing from a 
source to a sink in the context of CLBs and GRMs of an 
FPGA; 

FIG. 7 is a flowchart of a process for routing from a single 
source to a single sink in accordance with one embodiment 
of the invention; 

FIGS. 8A-8F to illustrate 12 templates generated for an 
input source and sink; 

FIG. 9 is a flowchart of a process for routing from a single 
source to multiple sinks in accordance with one embodiment 
of the invention; 

FIGS. 10A-10D illustrate, in sequence, the construction 
of a path in routing from a single source to multiple sinks 
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using ihe process of FIG. 9 for a first example including a 
source and multiple sinks; and 

FIGS. 11A-11D illustrate, in sequence, the construction 
of a path in routing from a single source to multiple sinks 
according to a second example. 

DETAILED DESCRIPTION 

Design of a circuit implemented in an FPGA using a 
rcconfigurablc logic coprocessor currently requires a com- 
bination of two distinct design paths, as shown in FIG. 1. 
The first and perhaps most significant portion of the effort 
involves circuit design using traditional CAD tools. The 
design path for these CAD tools typically comprises enter- 
ing a design 101 using a schematic editor or hardware 

-■description language (HDL), using a netlister 102 to gener- 
ate a net list 103 for the design, importing this netlisl into an 
FPGA placement and routing tool 104, which finally gen- 
erates a bitstream file 105 of configuration data used to 

_cpnfigure the FPGA 106. 

Once the configuration data has been produced, the next 
task is to provide software to interface the processor to the 
FPGA. The user enters user code 107 describing the user 
interface instructions, which is then compiled using com- 
piler 108 to produce executable code 109. The instructions 
in executable code 109 are then used by the processor to 
communicate with the configured FPGA 106. It is also 
known to use executable code 109 to control the configu- 
ration of FPGA 106 with bitstream file 105. This series of 
tasks is usually completely decoupled from the task of 
designing the circuit and hence can be difficult and error- 
prone. 

In addition to the problems of interfacing the hardware 
and software in this environment, there is also the problem 
of design cycle time. Any change to the circuit design 
requires a complete pass through the hardware design tool 
chain (101-106 in FIG. 1). This process time is time 
consuming, with the place and route portion of the chain 
typically taking several hours to complete. 

Finally, this approach provides no support for run-time 
reconfiguration. The traditional hardware design tools pro- 
vide support almost exclusively for static design. It is 
difficult to imagine constructs to support run-time recon- 
figuration in environments based on schematic or HDL 
design entry. 

FIG. 2 is a block diagram of a system 200 for configu- 
ration of a programmable logic device 202, according to one 
embodiment of the invention. It will be appreciated that 
system 200 also supports run-time reconfiguration of the 
programmable logic device 202. 

System 200 includes a user application program 204 that 
is written in the Java® language, for example. The appli- 
cation program 204 may be written to perform various 
functions relative to the environment in which system 200 is 
used. For example, in addition to configuration and/or 
run-time reconfiguration of programmable logic device 202, 
the user application program 204 may be programmed to 
provide user- interface functions and/or digital signal pro- 
cessing. 

Core library 206 is a collection of macrocell or "core" 
generators that are implemented as Java classes. The cores 
are generally parameterizable and relocatable within a 
device. Examples of cores include counters, adders, 
multipliers, constant adders, constant multipliers, flip-flops 
and other standard logic and computation functions. 

Bit-level interface 208 includes an application program 
interface that allows the user application program 204 to 
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manipulate configurable resources of programmable logic 
device 202. The bit-level interface also includes a set of 
functions, one or more of which are invoked when the user 
application program 204 references the application program 

s interface. The set of functions in the bit- level interface 
manipulate selected ones of programming bits 210, based on 
the type of programmable logic device. For example, some 
of the functions in the set may be programmed for certain 
devices in the XC4000EX family of FPGAs from XIUNX, 
and others of the functions may programmed for other 
devices in the XC4000XL family. Bit-level interface soft- 
ware is generally understood by those skilled in the art. For 
example, bit-level interface software has been provided with 
the.XC6200 series FPGA from XILINX. 
The programming bits are stored in storage element 212. 

15 Storage element 212 may be magnetic, optical, electronic, or 
a suitable combination thereof that is readable and writable. 

While core library 206, user application 204, and bit-level 
interface 208 are written in Java in the example 
embodiment, it will be appreciated that many other lan- 

20 guages would also be suitable. 

Hardware interface 214 includes a portable layer of 
software and accompanying hardware to couple application 
program 204 to programmable logic device 202. For 
example, hardware interface 214 may be the Xilinx Hard- 

25 ware Interface (XHWIF) which is available from XILINX. 
Processor 216 is coupled to programmable logic device 
202 via hardware interface 214. The functional requirements 
of system 200 dictate the particular style and capabilities of 

30 processor 216. For example, some applications may call for 
a RISC based processor while others may call for a CISC. 
Various ones of special purpose or general purpose proces- 
sors from manufacturers such as Intel, Sun Microsystems, 
Motorola, IBM, AMD and others may be suitable. 

35 FIG. 3 is a flowchart of a process for initial configuration 
and run-time reconfiguration of a programmable logic 
device according to an one embodiment of the invention. In 
accordance with an example embodiment of the invention, 
the process can be implemented as an application program, 

40 for example, user application program 204 of FIG. 2. The 
example process proceeds in two phases. In the first phase, 
the programmable logic device is initially configured, and in 
the second phase, the device is dynamically reconfigured in 
accordance with application processing requirements. 

45 At step 302 various components in the example system, 
aside from the programmable logic device, are initialized. 
The process then proceeds with configuration of the pro- 
grammable logic device. At step 304, an initial configuration 
bitstream is generated. For example, the bitstream can be 

50 generated using a core library to generate core logic along 
with routing configuration. Based on the generated logic 
cores and router cores, the bit-level configuration bitstream 
is generated to configure the programmable logic device 
202. The initial configuration bitstream is downloaded to the 

55 programmable logic device 202 at step 308, and the pro- 
grammable logic device is made an operational component 
of the example system 200 at step 310. 

Step 312 begins the run-time phase of processing by 
application program 204. Application program 204 includes 

60 code to monitor various application conditions, as illustrated 
at step 314. An example application provides adaptive 
digital filtering, which depends on various real-time system 
conditions. Run-time reconfiguration may also be initiated 
by, for example, user command line inputs, user GUI inputs, 

65 and the state of programmable logic device 202. . 

Al step 316, application program 204 selects the logic 
elements, which define the circuit implemented by the 
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programmable logic device, to be modified based on the 
information from step 314. New logic and configuration bits 
are generated at step 318, for example, using techniques 
described in the co-pending patent applications. At step 320, 
new configuration bits are generated to route the new logic 
using the application programming interface and associated 
techniques described herein. Processing then proceeds to 
step 308. 

It will be appreciated that downloading the bitstream as 
set forth in step 308 can involve either a partial reconfigu- 
ration or full reconfiguration of the programmable logic 
device 202. For example, the XC4000 scries FPGAs from 
XILINX support only full reconfiguration, whereas the 
Virtex FPGA, also from XILINX, supports partial recon- 
figuration. Thus, usage of the term "bitstream" is intended to 
encompass sequences of programming bits for both partial 
and full reconfiguration. 

FIG. 4 is a functional block diagram that illustrates 
various configurable routing resources of a programmable 
logic device, for example, the Virtex FPGA from Xilinx. A 
single paired general routing matrix (GRM) 350 and con- 
figurable logic block (CLB) 352 are illustrated. The actual 
device is comprised of a plurality of such pairs in a matrix 
arrangement. 

Each CLB includes configurable direct connections to 
horizontally adjacent CLBs, as shown by lines 354 and 356. 
For example, the Virtex FPGA allows output ports YB, Y, 
YQ, XB, X, and XQ to be connected to input ports G1-G4, 
BY, BX, and F1-F4 of a horizontally adjacent CLB. Output 
ports from CLB 352 can be configured to connect to GRM 
350 via signal line 358. Selected output ports can also be 
configured to connect to feedback to input ports of the CLB. 
Signal lines of GRM 350 can be configured to connect to the 
input ports of CLB 352, as shown by line 360. 

GRM 350 is a switch matrix through which horizontal and 
vertical routing resources connect, and is also the means by 
which CLB 352 gains access to the general purpose routing. 
The general purpose routing resources of GRM 350 include 
single -length lines ("single lines"), hex-length lines ("hex 
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FIG. 5 is a block diagram illustrating a partial row of 
CLBs and GRMs for an FPGA. A set of single lines and hex 
lines are shown connecting the GRMS. It will be appreciated 
that additional routing resources arc available for 
configuration, such as long lines, even though the resources 
arc not illustrated. Line 402, for example, represents the east 
single lines that terminate in GRMs 404 and 406, and line 
408 represents the cast hex fines that terminate in GRM 404. 
It will be appreciated that a set of hex lines 408 connect 
GRM 404 to GRM 410, which is 6 GRMs away. Thus, CLB 
412 can be connected to CLB 414 via a single hex line. 
Similarly, GRM 416 connects to GRM 418 via a set of hex 
lines. 

Within each GRM, the single lines, hex lines, and long 
lines can be selectively connected to in order to interconnect 
input and output ports of selected CLBS. CLB outputs can 
drive any length line, long lines can drive hex lines only, hex 
lines can drive other hex lines and single lines, and single 
lines can drive CLB input ports, vertical long lines, and other 
single lines. The connections between the lines are made by 
turning on selected bits in the configuration bitstream and 
loading the configuration bitstream into the programmable 
logic device while the device is enabled for configuration. 

FIG. 6 is a block diagram illustrating routing from a 
source to a sink in the context of CLBs and GRMs of an 
FPGA. The solid thick lines represent hex lines used in the 
connection, and the dashed thick lines represent single lines. 
The source is one of the output ports of CLB 452, and the 
sink is one of the input ports of CLB 454. 

In various embodiments, the present invention supports 
generating bits to configure routing resources via an appli- 
cation programming interface. The interface provides mul- 
tiple levels of control over the routing task. In one 
embodiment, a source and a sink are provided as input data, 
and the route from the source to the sink is performed 
automatically. In another embodiment, a template is pro- 
vided as input data, and the route is performed consistent 
with the template. Further control over the route can be 



lines"), and long lines. Lines 362, 364, 366, and 3 6 8 40 exercised by specifying a path that specifically identifies the 
represent the collection of single, hex, and long lines to resources to use in the route. 

For purposes of describing the various embodiments of 
the invention, the CLBs are referenced by row and column 
numbers, with the southernmost and westernmost CLB at 
row 0, column 0 (abbreviated as CLB 0,0). The CLBs of 
FIG. 6 are the CLBs at rows i through (i+x+1) and columns 
j through (j+y+1). 

The task of routing from source CLB 452 to sink CLB 454 
generally involves identifying the routing resources that are 
available and selecting a suitable path. The shortest path is 
generally the most desirable. In the example, a first connec- 
tion is established between the specified output port of CLB 
452 and hex line 456 via connection switch 458. It will be 
appreciated that switch 458 is configurable with a particular 
bit in a configuration bitstream. One or more additional hex 
lines are then connected in an easterly direction until GRM 
460, depending on the number of columns between columns 
j+1 and j+y. The last EAST6 line is line 462, which is 
connected to the first SOUTH6 line 464. The last SOUTH6 
line 466 connects to the first EAST line 468 at GRM 470. 
EAST line 468 connects to SOUTH line 472, which is 
connected to a designated input port of CLB 454. 

The embodiments of the present invention support a 
variety of run-time routing tasks. For example, application 
programming interfaces are provided to route from a single 
source to a single sink, route from multiple sources to 
respective sinks, and route from a single source to multiple 



adjacent GRMs in the four directions (north, south, east, and 
west), respectively. 

There are 24 single lines to adjacent GRMs in each of the 
directions for a total of 96 single lines. A single line is 
referenced herein by direction, for example, NORTH. 
Ninety-six buffered hex fines route signals to GRMs that are 
six blocks away in each of the four directions. Organized in 
a staggered pattern, hex lines may be driven only at their 
endpoints, but can be accessed either at an endpoint or a 
midpoint tap. One third of the hex lines are bi-directional, 
and the remaining hex lines are uni-directional. A hex line is 
referenced herein as Direction6, for example, EAST6. Long 
lines are buffered and bi-directional wires that distribute 
signals across the device. There are 12 vertical long lines per 
column that span the entire device from north to south, and 
12 horizontal long lines per row that span the device from 
west to east. CLBs have access to long lines every 6 
rows/columns in a staggered pattern. Thus, each CLB has 
access to two horizontal long lines and 2 vertical long lines 
in the associated GRM. 

"Wire" is used herein to refer to any routing resource, 
including CLB inputs, CLB outputs, output multiplexers 
(muxes), long lines, hex lines, single lines, and Tbufs in the 
context of a Virtex FPGA. Those skilled in the art will 
recognize comparable resources for other programmable 
logic devices. 
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sinks. In addition, programming interfaces are provided to single lines 516. Thus, FIG. 8A actually illustrates two 

manage run-time routing, such as un-routing, checking templates, with the second template including a sequence 

whether a wire is configured, explicitly generating paths, such as source, SOUTH6, SOUTHS, . . . , EAST6, 

and generating paths with templates. EAST6, . . . , EAST, EAST, . . . SOUTH, SOUTH, .... sink. 

The application programming interfaces of the present 5 The first template consisting of the solid lines, and the 

invention are implemented in an object oriented program- second template consisting of the lines from the source to 

ming language in one embodiment. The primary classes connection point x, and the dashed lines from x to the sink, 

include the Pin, Router, Template, and Path classes. The Pin it will be appreciated from the foregoing that FIGS. 8A--8F 

class defines a physical cod point, the Router class generally illustrate 12 different templates, 

provides automated routing methods, the Template class t° 

generally provides methods for defining templates, and the FIG - 8B illustrates template 518 in which horizontal hex 

Path class generally provides methods for defining paths. uncs are first addcd 10 the template followed by the vertical 

Before describing the application programming interfaces in hex lines. Single lines 520 are added to the template first in 

detail, a process for routing from a source to a single sink is the vertical direction followed by single lines 522 in the 

described in order to illustrate pins, paths, and templates. 15 horizontal direction. Another template is defined with hori- 

FIG. 7 is a flowchart of a process for routing from a single z°ntal single lines added to the template before the vertical 

source to a single sink in accordance with one embodiment single lines. 

of the invention. The process generally entails generating a FIG. 8C illustrates a template 524 in which a midpoint m 

plurality of templates, attempting to route using the ^ idcntificd ^ mc t latc ^ dcfincd t0 thc 

templates, and establishing a path consistent with a template. ., . . „, c , , . „ , , . ,,. 

r ° r r midpoint. The first step in generating the template is adding 

Atstep 502, a selected number of templates are generated. horizonlal hex lines followed b verticaJ hex ^ between 

Reference is made lo FIGS. 8A-8F to lUustrate 12 templates {hc SQmcc ^ ^ mid ^ ^ ncxt ^ tQ add verlica , 

generated for an mput source and sink. Generally, a template , c „ , , , . ... , . , ^ 

r j . £ , . . l r n j hex lines followed by horizontal hex lines between the 

is an ordered set oi types of routing resources to be followed „„....-,, , . . a 

in routing from a source to a sink The set of directions are 25 midpoint and x. Two alternative templates are then defined 

designated as resource types. The resource types include as desenbed ^ove by using single lmes between x and the 

EAST, WEST, NORTH, and SOUTH for the single length smk 

lines; EAST6, WEST6, NORTH6, and SOUTH6 for the hex FIG. 8D illustrates a template 526 in which vertical hex 

lines; HORIZ_LONG and VERT_LONG for the long 3fl followed by horizontal hex lines are added to the 

lines; CLB_1N and CLB„OUTMUX for CLB input and tcmplalc bc(WCCD mc sourcc and thc midpoint . Frora thc 

output ports; HORIZM and VERTM for describing taps in midpoin t t0 X) vertical hex lines are first added followed by 

the middle of horizontal and vertical hex lines; and horizonlal hex ]ilies . ^ single lines m added to the two 

S1NGLE_FEEDBACK for connecting an output multi- mennt tem U(es between x the sink as described 

plexer to a smgle line and also connect that single line to a 35 above FIGS 8E and 8F illustrate 4 Mt i onA i lemp iates, all 

CLB input port. passing through the midpoint. 

Each of the templates illustrated in FIGS. 8A-8F is shown 

with source and sink end points as labeled, small circles that Returning now to step 552 of FIG. 7, an arbitrary one of 

symbolize connection points, longer lines that symbolize the templates is selected. At step 554, a route is attempted 

one or more hex lines, and shorter lines that symbolize one , 0 from the 10 the sink consistent with the selected 

or more single lines. template. If there were routing resources available consistent 

tv,- t ,„„i, ( „ „„ i • a „ ci . with the template and the route was a success, decision step 

Inc templates arc generated in a generally systematic __, r __ 0 , ' „ ... . r 

fasmon.FIG.8Ashowsafir S toneof thetemplates. Template 556 dl ' ectS Pressing *> step 558^ where the EndPoint is 

504 is generated by first including a number of hex lines in re f urncd t0 program. Tne EndPoint is the final 

i j- .• F t u . j . ,u i wire connected in the path. If routing resources were 

a vertical direction from the source toward to the sink 45 . , . . r . . , , b , , . . 

followed by a number of hex lines in a horizontal direction. consistent with the selected template, decision 

Note that "vertical" and "horizontal" refer to row and ste P 556 dl f ects P^ing to decision step 560 to test for 

. j-i . , . more templates. It there are more templates lor which to 

column displacement, respectively. The number of vertical „ . . r . „ c „ , „ 1( f c , 

and horizontal hex lines Spends on the number of rows and a tem P l io A route > ste P 56 l selec ! s ° ne * ^ . tem ' 

columns thai separate the source and the sink. The set of 50 pl T* ^ d P rocessin S 15 t0 stc P 554 " Otherwise, a 

vertical hex lines are designated as 506, and the set of nul1 value 15 returaed to the cdhn S P ro S ram - 

horizontal hex lines are designated as 508. After the hex Turning now to the classes that implement the application 

lines have been specified in the template, the single lines are programming interfaces, an object of the class pin defines a 

added to the template. First, single lines are added to the physical endpoint consisting of a row, column, and wire, 

template in the vertical direction toward the source, and theo 55 yjj e q\ &s& "Router*' 

sinde lines are added to the template horizontally toward the ™ , ... iL , „ . , , 

source. The vertical single lines are designated as 510, and router mc ' lldes lhe followm e me * ods: roilte * 

the horizontal single lines are designated as 512. It will be 8*P«h, «On, remove Connection, unroute, and reverseun- 

appreciated that the number of horizontal and vertical single ™ te ™ c routc ^thod automatically routes from a sourcc 

lines required depends on location at which the hex lines 508 60 to a «nk, » specked wiih mput parameters. The following 

terminate relative to the sink. The template described thus P»«R«Pl» d « c "be the format J^ncton of the apphca- 

far would include a sequence such as source, SOUTH6, tion programming interfaces embodied m the dififerent route 

SOUTH6, . . . , EAST6, EAST6 SOUTH, SOUTH methods. 

EAST, EAST, . . . sink. public Connections[ ] route(int row, int col, int from, int to) 
Dashed lines 514 and 516 also illustrate single lines for an 65 This route method routes a single connection. The con- 
alternative template. In contrast to template 504, horizontal figuration bilstream is updated if the route was suc- 
single lines 514 are added to the template before vertical cessful. 
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The parameters include: 
row — the CLB row 
col— the CLB col 

from — (he wire that is doing the driving 

to — the wire that is being driven 
The method returns an array of connections that represents 
the specific connections of wires or null if qo connection is 
made. 

public Connections [ ] [ ] route(EndPoint[ ] source, 

EndPoint[ ] sink) 
This route method routes each of the connections from 
each of the sources in EndPoint[ ] source to each of the 
sinks in EndPoint[ ] sink. The parameters source and 
sinkmust be the same length. 
The method returns a double array of final connections. 
The array will be the same length as the input arrays 
and includes the final wires connected. An element will 
be null if the connection was not routed. The configu- 
ration bitstream is updated for routes that were suc- 
cessful. 

public Connections[ ] routc(EndPoint source, EndPoint 
sink) 

This route method finds a path routed from EndPoint from 
to EndPoint to and sets the proper bits in the configu- 
ration bitstream. 
The method returns an array of Connections and returns 
null if no connection is made, 
public Conneclions[ ] route(Pin start, int end_wire, Tem- 
plate temp) 

This route method finds a path routed from start to 
cnd_wirc using the input Template parameter, temp, 
and sets the proper bits in the configuration bitstream. 
The route method searches for routing resources that are 
consistent with the resources specified in the template, 
beginning at the source. 
The method returns an array of Connections, 
public Connections [ ] [ ] route(EndPoint source, EndPoimf 
] sink) 

This route method routes from a single source, EndPoint 
from to multiple sinks, Endpoint[ ] and sets the appro- 
priate bits in the configuration bitstream. 
Format and Function 

The format and function of the application programming 
interfaces embodied in the methods, getPalh, isOn, remove 
connection, unroute, and revcrseunroute, are described in 
the following paragraphs. 

public Path getpath(int row, int col, inl start, Template temp) 
This getPath method finds a path given an input template 
parameter. No end wire is specified. In this case, the 
router will find the right type of resource and return the 
particular instances of the resources that were used. The 
parameters include: 
row — the CLB starting row 
col — the CLB starting column 
start — the starting wire 
temp — the template to follow to get from the 
start to end 

public Path getpath(int row, inl col, int start, int end, 
Template temp) 

This getpath method finds a path given an end wire input 

parameter, end, and an input template parameter. The 

parameters include: 

row — the CLB starting row 

col — the CLB starting col 

start — the starting wire 
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end — the ending wire 

temp — the template to follow to get from the start to 
end 

public boolean isOn(int row, int coL int wire) 
5 This method checks whether the specified wire is on as 
indicated in the configuration bitstream. 
public Connections [ ] remove connection(int row, int col, 
int from, int to) 
This method removes the specified connection by clearing 
10 the specified bit in the configuration bitstream. The 
parameters include: 
row — the CLB row 
col— the CLB col 

from — the wire that is doing the driving. 
35 to — the wire that is being driven. 

public Connections [ ] unroute(EndPoint start) 

This method turns off connections and releases the 
resources of a circuit beginning at the EndPoint start. 
All connections of paths to all sinks are removed by 
clearing the appropriate bits in the configuration bit- 
stream. 

public Connections [ ] reverseUnroute(EndPoint start) 
This method turns off connections and releases the 
M resources of a circuit starting from the EndPoint start 
and working backwards. All connections are removed 
up to the point where a wire is one of several wires 
being driven. 
The Class "Path" 
iQ An object of the class path includes a row and a column 
that are represented with respective integers, along with an 
array of integers that sets forth the path. A path indicates 
specific resources to be used to connect a source and sink (as 
compared to a template which indicates directions and types 
iS of resources to be used in a connection). The format and 
function of the application programming interfaces embod- 
ied in methods addpath, addStart, and addwire are described 
in the following paragraphs. 

public void addPath(int row, int col, int[ ] palh_arr) 
4D This method can be used to connect to a line without 
tapping the line at its end point. For example, if a path 
already includes S0_XQ to Out[0] to VertLong[0], 
add Path could be used to connect VertLong[0] at CLB 
row+12,col (which is the same long vertical wire as 
45 presently in the path but in a different row) to HexWest 
[0] to SingleWesttO] to S0F1. This path includes two 
path segments comprising a single path. The method is 
an alternative to the adds tart and addwire methods 
described below. . 
so public void add\Vire(int wire) 

This method adds a wire to the current path, 
public void addStart(int row, int col, int wire) 
This method adds a starling point to the current path. This 
is used in cases where the tap point is not implicit in the 
ss wire, such as a long line or if a hex line is to be tapped 
at the midpoint. The parameters include: 
row — the starting CLB row 
col — the starting CLB col 
wire — the starting wire 
60 The Class "Template" 

An object of the class template includes a set of directions 
to be used by the route method in establishing connections 
from a source to a sink. Templates specify types of 
resources, not actual resources, thereby allowing the routing 
65 process to determine if there are resources available of the 
type and direction specified in the template. The formal and 
function of the application programming interfaces embod- 



11/07/2003, EAST Version: 1.4.1 



US 6,487,709 Bl 

11 12 

ied in the methods, adddirection and addTapLocation, are Ai step 620, the expansion list is cleared, and decision 

described in the following paragraphs. step 620 tests whether there are more sinks to which routing 

public void addDirection(int dir) is required. If so, processing proceeds to step 622 to get the 

This method adds a direction to the template. If the next sink. At step 623, the segments in the path arc added to 

direction is a long line or a hex line to be used for 5 the list of used segments, and at step 624, the segments from 

midtap, the row and col offcet must be defined. the used segments list arc put in the expansion list using the 

public void addTapLocationfint row, int col) cost fraction described above for the new sink in process. 

This method defines the tap offset for Midtap hexes and Processing proceeds to step 606, where track segments are 

l on g s r added to the expansion list. 

10 FIGS. 10A-10D illustrate, in sequence, the construction 

EXAMPLES of a path in routing from a single source to multiple sinks 

, , , j . . , » . using the process of FIG. 9, according to a first example. A 

Example code that uses the preceding the methods is scc0Qd , e fa iIluslrated m HGS UA _ 11D . ^ 

provided following the descriptions for FIGS. 9, 10A-10D, ^ markcd ^ ^ « x , and ^ ^ arc empty boxes ^ 

and 11 A 11 D. . 15 examples are not intended as a detailed illustration of the 

FIG. 9 is a flowchart of a process for routing from a single slep-by-siep construction of the path using the process of 

source to multiple sinks in accordance with one embodiment p[Q 9 Instead, the figures are intended to generally illus- 

of the invention. The process attempts to construct the Uaie tne reuse 0 f segments in routing from a source to 

shortest paths that are feasible in routing from the source to multiple sinks. 

me multiple sinks, while minimizing the routing resources 20 . . 

, • t w th FIG. 10A shows the initial state in which no wires have 

used in me pains. been &dd ^ ^ ^ pa(h Iq fig ^ (he source hag bgen 

The process begins at step 602 where the sinks are sorted routed tQ &ink 652 via path 654 Palh 654 is comprised of a 

in the order of respective distances from the source, with the scqucncc of long> hcXj and sing i e iin CSj as needed to connect 

closest sink being the first in the order. The distance is me samx {Q sink 652 Nole mal lhe reUtive lengths of me 

measured in numbers of rows and columns separating the « lincs that form thc path afc nQt indicalivc of mc typcs of 

source and sink. For example, the distance separating CLB Unes 

10,10 and CLB 15,15 is 10 (5 columns+5 rows). • , . . 

™* L c c l j • 1 • j j a. In FIG. 10C, thc source is routed to sink 656. Note that the 

At step 604, the first of the sorted sinks is considered At ^ ^ ^ ^ ^ ^ q{ ^ 

step 606, an expanston list is constructed^ The expansion Ust iQ » ^ ^ fiM ^ ^ frQm fa 
is a list of segments that is ordered by cost, where the 654 ^ coQnecl ^ ^ ^ 
cost(segment)-K*minTracks{segment). K is a predeter- 
mined constant, and minTracks(segment) is the minimum A path is constructed to sink 660 in FIG. 10D. Portions of 
number of resources needed to route from the sink to the paths 654 and 658 are reused in constructing the path to sink 
segment. A segment is generally either a single wire or a 35 660. Segment 662 connects sink 660 to segment 658. 
collection of connected wires. The segments added to the F1GS ha-11D illustrate, in sequence, the construction 
expansion list at step 606 are the "track segments." Track 0 f a pam m rou tmg from a single source to multiple sinks 
segments are any wires that the source drives directly. For according to a second example. FIG. 11 A shows the relative 
example, the track segments for a CLB include the hex lines locations of the source and sinks. In FIG. UB, path 670 has 
and single lines that the CLB can drive from its output ^ beeQ constructed between the source and the closest sink, 
multiplexers. sink 672. 

At step 608, the lowest cost segment is removed from the [q rg ^ nm ^ ^ m {& connected 

expansion list, and step 610 begins a process loop o ^ ^ A iQn flf Q m ^ reused and ext£nded 

construct a path from the segment to the selected sink. ^ ^ m [q ^ fi?4 ^ m b hnhc&l 

Decision step 610 tests whether the sink in process can be 45 from ^ ^ fc ^ ^ ^ mnnec1ed t0 the 

reached from the selected segment. If not, processing pro- ^ Somc rf ^ from ^ {q ^ fi?4 afc 

ceeds to step 612. At step 612 the segments to which he ^ ^ ^ ^ 68Q {Q tQ ^ 

selected segment can connect ( neighbors ) are added to the m ^ ^ bc jated ^ as bclwccn alh 670 

expansion Ust using second cost function where cost (c0Qnecti tfae source t0 sink 672) and th 676 

(neighboO-costCsegmentHcos^^minTracksfneighbor). 50 connccti thc to sink 674)> ^ occss 

Cost, is a cost value that is associated with a type of wire. ^ ^ ^ ^ rf fi70 ^ 6gQ ^ 

For example long lines have a cost value 500 to avoid usage ^ additional TesouTCCS than wouid a path mat extcnds 

thereof, hex lmes and single lines have cost values 1, and ^ ^ 
direct connections have a cost value 0. 

At step 614, thc lowest cost segment is removed from thc 55 ^ following snippets of sample code illustrate usage of 
expansion list and added to the path under construction. For programming interfaces provided with the present mven- 
an example route in which two segments have been thus far tion - Comments are interspersed in the code to explain the 
added to the path, the path may include HexEast{0], HexEast functionality. 
[20], which represents two particular cast hex lines. Pro- 
cessing returns to decision step 610 from step 614 and the 60 ^ -^—^^ 
loop is repeated until the sink is reached. Note that at step f . AUm ROUTE . BUra ^ sink 7 
612, the segment that was most recently removed from the /• c ias S wires has all of the wire definitions as 
expansion list is the segment from which the neighboring constanu */ 

segments are determined. £ S0UI « ' row " 13 ' ^T 1 , 5 ; ^ S °-*° 

to „ . Pin source - new Pm(13,15,Wires.S0_XO); 

When the sink is reached, decision step 610 directs 65 /• ^ . row -22, col-40, wire-soFi */ 

processing to step 616 where lhe path is routed. That is, the Pin sink - new Pin{22,4O,Wires.S0Fi): 

appropriate bits are set in the configuration bitstream. 
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-continued 



-continued 



/" route (Pin source, Pin sink) - auto routes single 
source to single sink */ 

Connections [ ] connections- j route, routefsource, sink); 
/* AUTO ROUTE - source to several sinks */ 

I' source - row-22, col-22, wirc-S0_XQ 7 

Pin source • new Pin(22,22,Wires.S0_XQ); 

/• 2 sinks V 

Pin{ 1 sink - new Pin(2fc 

y* sink - row-27, col-30, wire-SOFl */ 

siniJO] - new Pin(27,3a,Wiics.S0Fl); 

/" sink - row-2, col-1, wirc-SlGl */ 

sinktl] - new Pin(2,l,Wtres.SlGl); 

/* rouie(Pin source, Pin| ] sink) - auto routes single 
source to several sink 7 

jroute.ro uie(jource, sink); 
/• AUTO ROUTE - several sources to several sinks V 

I* 2 sources */ 

Pin source - new Pin[2]; 

/" source - row-22, col-22, wire«S0_XQ ■/ 

source[0] - new Kn(22,22,Wires.S0_XQ); 

I' source - row-1, col-13, wiie-Sl_YQ */ 

source(0] - new Pin(l,13,Wires.Sl_YQ); 

/• 2 sinks V 

Pint ] sink - new Pin[2); 

7* sink - row-27, col-30, wire-SOFl V 

sinkJO] - new Pin(27 r !0,Wire6.S0Fl); 

/* sink - row-2, col-1, wire-SlGl */ 

sinktl] - new Pin(2,l,Wires.SlGl); . 

/* route(Pin[ ] source, Pin[ ) sink) - auto routes 
multiple sources to multiple sinks •/ 

j route. roule(souicc, sink); 
/■ Define a template - way 1 ■/ 

Template t - new Template (); 

try { 

t.addDircction{Wir«.CLBOUTMUX); 
UddDirectionCWires.HORIZM); 
t.addTapLocation{0,-3); 
t.addDiiection(Wires.SOUTH); 
t,addDirection(Wres.CLBIN); 
}catch CTfemplateException te) { 
System.exil(-1) 

} 

/• rouie(int start_jow, int start_col, int start_wire, 

ini end_wire. Template) •/ 
Pin staril - new Pin(lO,10,Wires.SO_XQ); 
jroute.route(starll .Wires.SOFl.t); 
/* can use the same template for another route */ 
Pin startZ - new Ptn(ll,ll,Wires.SO_JCQ); 
j'route.route(stara,Wires.SOF],t); 
/* Define a template - way 2 "/ 

/* define a template that involves an outrmix, a HexWest, 

a SingleSouth, and a CLB Input '/ 
intj ) temp - { Wires.CLBOUTMUX, Wires. WESTS, 

Wires-SOUTH, Wires.CLBIN }; 
Template t - new Template(temp); 
/• route(int start_row, int itart_col, int start_wire, 

inl end_wire, Template) */ 
Pin startl - new Pin(lO.lO.Wires.SOXQ); 
jroute.route(6tartl ,WireB.SOFl ,t); 
/* can use the same template for another route */ 
Pin st*rt2 - new Pin(ll 1 ll,Wires.SO_XQ); 
jroute.route(start2,Wirea.S0Fl,t); 
/• Define a Path - way 1 7 

/" the class Path is a way to define an array of 

resources not path based in nature */ 
Path p - new Path( ); 
/* Start at 10,10, SCLJiQ V 
pJ1 ddStart(10 I 10,Wi r e S .SO_XQ); 
/* connect to Oud.2] "/ 
pj»ddWire(Wu-«.Outl2D; 
/• connect to LongHoriz|0] */ 
p .addWire(WiTes.LongHorizl OD ; 
/• at 10,22 tap the LongHoiizfO] */ 
p.addstartOO.22, Wires. LocgHoriztOD; 
/• connect it to HexEast(0] */ 
p^ddWire(Wiies.H«cEasttOD: 
/* connect it to SingleEast(0] V 
pjddWire(Wires.SuigleEastl22l); 
/* connect it to S0F1 */ 
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p.addWiie (Wires.SOPl); 

/* routefPath path) V 

jroute.route(p); 
/* Define a Path - way 2 */ 

/• define the path as an int array */ 

intt ] path - { Wires.SO_XQ, Wires.OuttOl 

Wires-DiiectEasttO], Wirts.S0F2 } 

/* create a Path object */ 

Path p - new Path(14,l5,path); 

/* routefPath path) */ 

jroute.ioute(p); 
I* Single connection */ 

/* turn on the connection from SingleNorthtOJ to 
SingleSouthlO] in db (14,22) V 

/* route(int row, int col, int from, int to) */ 

jroute.route(14, 22, Wires.SingleNorth[Dl Wires.SingleSouth(OD; 
/* unroute - forward V 

/• turn off all connections that are souiced by S0_XQ in 
(11,22) V 

Pin sre - new Pinfll^.Wirei.SO^XQ); 

/* un route (Pin source) */ 

j route .unioulc (sre); 
/• unroute - reverse */ 

/* turn off all connections on the branch that leads to 
S0F1 in (11,22) */ 

Pin sink - new Pin(ll,22 J Wires.S0Fl); 

/* reverseUnroutefPin sink) '/ 

]route.rcvcrseUnTOUte(sink); 
/* Check if a wire is on */ 

/• check if SingleWest{0] in elb (12,49) is on *l 

/* isOn(int row, int col, int wire ) */ 

boolean on - jroute.isOn(12, 49, Wires.SingleWesttO]); 
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The present invention is believed to be applicable to a 
variety of processes for implementing circuit designs and 
has been found to be particularly applicable and beneficial in 
PLDS. While the present invention is not so limited, an 
appreciation of the present invention has been provided by 
way of specific examples involving PLDs. Other aspects and 
embodiments of the present invention will be appareot to 
those skilled in the art from consideration of the specifica- 
tion and practice of the invention disclosed herein. It is 
intended that the specification and illustrated embodiments 
4,0 be considered as examples only, with a true scope and spirit 
of the invention being indicated by the following claims. 
What is claimed is: 

1. An application programming interface for configuring 
routing resources of a programmable logic device, compris- 
es ing: 

a first function configured and arranged to automatically 
generate configuration bits for configuration of routing 
resources that connect a source to a sink responsive to 
input data specifying the source and sink; 
a second function configured and arranged to automati- 
cally generate configuration bits for configuration of 
routing resources that connect a source to a plurality of 
sinks responsive to input data specifying the source and 
the plurality of sinks. 

2. The interface of claim 1, further comprising a third 
function configured and arranged lo generate configuration 
bits for configuration of routing resources that connect a 
source to a sink consistent with a set of types of resources 
responsive to input data specifying the types of resources. 

3. The interface of claim 2, wherein the set of types of 
resources is an ordered set. 

4. The interface of claim 3, further comprising a fourth 
function configured and arranged to add a resource type to 
the ordered set responsive to input data specifying the 
resource type. 

5. The interface of claim 1, wherein the first function is 
further configured and arranged to generate a plurality of 
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ordered sets of resource types and determine whether rout- 
ing resources can be configured consistent with any of the 
ordered sets of resource types. 

6. The interface of claim 1, further comprising a third 
function configured and arranged to generate configuration 
bits for configuration of routing resources that connect a 
plurality of sources to a plurality of sinks responsive to input 
data specifying the sources and sinks. 

7. The interface of claim 1, further comprising a third 
function configured and arranged to generate and output an 
ordered set of resource types beginning at a source and 
terminating at a sink responsive to input data specifying the 
source and sink. 

8. The interface of claim 1, further comprising a third 
function configured and arranged to generate configuration 
bits that release routing resources that connect a source and 
a sink responsive to input data specifying the source. 

9. The interface of claim 8, further comprising a fourth 
function configured and arranged to generate configuration 20 
bits that release routing resources beginning at a sink and 
proceeding toward the source responsive to input data 
specifying the sink, wherein releasing the routing resources 
stops where a routing resource is one of two or more routing 
resources driven at a connection point. 

10. The interface of claim 1, further comprising a third 
function configured and arranged to generate configuration 
bits for configuration of routing resources that connect a 
source to a sink responsive to input data specifying the 
source, sink, and specific routing resources comprising a 
path. 

11. The interface of claim 10, further comprising a fourth 
function configured and arranged to add a specific routing 
resource to the path responsive to input data specifying the 
specific routing resource. 35 

12. A computer-implemented method for configuration of 
routing resources of a programmable logic device, compris- 
ing: 

providing a program interface having as input parameters 
a source and a sink corresponding to an output port and 40 
an input port of configurable elements of a program- 
mable logic device, respectively; and 

generating configuration bits for configuration of routing 
resources for connection of the source and sink respon- 
sive to programming interface calls, 

13. The method of claim 12, further comprising generat- 
ing configuration bits that configure routing resources that 
connect a source to a sink consistent with a set of types of 
resources responsive to input data specifying the types of 
resources. 

14. The method of claim 13, wherein the set of types of 
resources is an ordered set. 
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15. The method of claim 14, further comprising: 
providing a program interface for constructing an ordered 

set of types of resources; and 
adding a resource type to the ordered set responsive to 
input data spetifying the resource type. 

16. The method of claim 12, further comprising generat- 
ing a plurality of ordered sets of resource types and deter- 
mining whether routing resources can be configured consis- 
tent with any of the ordered sets of resource types. 

17. The method of claim 12, further comprising generat- 
ing configuration bits for configuration of routing resources 
that connect a plurality of sources to a plurality of sinks 
responsive to input data specifying the sources and sinks. 

18. The method of claim 12, further comprising: 
providing a program interface for finding an ordered set of 

resource types; and 
generating and outputting one or more ordered sets of 
resource types beginning at a source and terminating at 
a sink responsive to input data specifying the source 
and sink. 

19. The method of claim 12, further comprising: 
providing a program interface to disconnect a source and 

a sink; and 

generating configuration bits that release routing 
resources that connect a source and a sink responsive to 
input data specifying the source. 

20. The method of claim 19, further comprising generat- 
ing configuration bits that release routing resources begin- 
ning at a sink and proceeding toward the source responsive 
to input data specifying the sink, wherein releasing the 
routing resources stops where a routing resource is one of 
two or more routing resources driven at a connection point. 

21. The method of claim 12, further comprising generat- 
ing configuration bits for configuration of routing resources 
to connect a source to a sink responsive to input data 
specifying the source, sink, and specific routing resources 
comprising a path between the source and the sink. 

22. The method of claim 21, further comprising: 
providing a program interface for constructing a path; and 
adding a specific routing resource to the path responsive 

to input data specifying the specific routing resource. 

23. An apparatus for configuring routing resources of a 
programmable logic device, comprising: 

means for automatically generating configuration bits for 
configuration of routing resources that connect a source 
to a sink responsive to input data specifying the source 
and sink; and 

means for automatically generating configuration bits for 
configuration of routing resources that connect a source 
to a plurality of sinks responsive to input data speci- 
fying the source and plurality of sinks. 
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